<html>
<head><meta charset="utf-8"><title>Stack smash protection · wg-secure-code · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/index.html">wg-secure-code</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html">Stack smash protection</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="226303807"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226303807" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benjamin <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226303807">(Feb 14 2021 at 13:14)</a>:</h4>
<p>Have I understood correctly that there's no stack smash protection in Rust, and that this means Rust code is more vulnerable to some exploits when calling unsafe code? Or is there a reason this is not a problem? (E.g. stack smashing across stack frames not being a thing, or that such attacks should be caught by canaries in the unsafe code). The use case I have in mind is creating safe Rust abstractions around pre-compiled vendor libraries, and I wonder if this is actually a two-edged sword security-wise: reduced chance of vulnerabilities in the client code, but fewer defenses if the library has a vulnerability.</p>



<a name="226304114"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226304114" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Gwaihir Thorondorsen <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226304114">(Feb 14 2021 at 13:23)</a>:</h4>
<p>It <a href="https://github.com/rust-lang/rust/issues/43241">depends on the platform</a>. I am pretty certain the main (tier 1) x86-64 targets are protected, but for instance <a href="https://github.com/rust-lang/rust/issues/77071">aarch64 is not (yet)</a>. IIUC, support mostly depends on LLVM for the implementation, but <code>rustc</code> needs to enable it explicitly.</p>



<a name="226304171"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226304171" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Gwaihir Thorondorsen <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226304171">(Feb 14 2021 at 13:24)</a>:</h4>
<p>I have no idea what the story is for the cranelift backend so I'll just defer to <span class="user-mention" data-user-id="133247">@bjorn3</span>.</p>



<a name="226304430"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226304430" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226304430">(Feb 14 2021 at 13:32)</a>:</h4>
<p>That's stack overflow protection, not stack smash detection.</p>



<a name="226304471"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226304471" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226304471">(Feb 14 2021 at 13:33)</a>:</h4>
<p>If the C library itself wasn't built with stack smash protection enabled and you wanted an extra layer of security, you could potentially make a little C shim that wraps the library by just directly delegating each method and then build that shim with stack smash protection enabled.</p>



<a name="226304829"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226304829" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benjamin <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226304829">(Feb 14 2021 at 13:44)</a>:</h4>
<p>Thanks, so  it's unlikely that an attacker can target an unchecked Rust stack frame as long as there's one with a canary somewhere further down the call stack? I guess that's the assumption which makes the canaries work at all :) What if the library is given a pointer to the Rust stack though? Should a Rust wrapper prefer sending pointers to heap-allocated data to unsafe code?</p>



<a name="226304872"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226304872" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Gwaihir Thorondorsen <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226304872">(Feb 14 2021 at 13:44)</a>:</h4>
<p>Naming things is hard indeed… (Sorry, that's my 2nd in less than 24h and its starting to get embarrassing.)</p>



<a name="226304978"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226304978" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226304978">(Feb 14 2021 at 13:47)</a>:</h4>
<p><span class="user-mention silent" data-user-id="369545">Gwaihir Thorondorsen</span> <a href="#narrow/stream/146229-wg-secure-code/topic/Stack.20smash.20protection/near/226304171">said</a>:</p>
<blockquote>
<p>I have no idea what the story is for the cranelift backend so I'll just defer to <span class="user-mention silent" data-user-id="133247">bjorn3</span>.</p>
</blockquote>
<p>Stack probing isn't supported by cg_clif yet. Cranelift does support it, but the <code>__rust_probestack</code> in compiler-builtins requires inline assembly. While this is partially supported on Linux, compiler-builtins uses some inline asm features that aren't yet supported, so I had to enable the <code>no-asm</code> feature of compiler-builtins.</p>



<a name="226310541"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226310541" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Shnatsel <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226310541">(Feb 14 2021 at 15:47)</a>:</h4>
<p>FWIW, out of all the advisories in <a href="https://rustsec.org/">https://rustsec.org/</a> I've only seen one that would have been prevented by stack smashing protection. I could have missed something, but stack buffer overflow is not a common failure mode in Rust code.<br>
I'm not qualified to comment on the interaction with C code.</p>



<a name="226310873"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226310873" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226310873">(Feb 14 2021 at 15:54)</a>:</h4>
<p>Overflowing a heap allocated buffer rather than a stack allocated buffer just results in heap corruption rather than stack corruption. At some point, you just have to make a call of how sloppy you think these libraries actually are, and if they're that bad you may need to e.g. isolate them to a separate process with limited permissions or something.</p>



<a name="226312547"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226312547" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Oliver Braunsdorf <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226312547">(Feb 14 2021 at 16:14)</a>:</h4>
<p><span class="user-mention silent" data-user-id="243558">Steven Fackler</span> <a href="#narrow/stream/146229-wg-secure-code/topic/Stack.20smash.20protection/near/226310873">said</a>:</p>
<blockquote>
<p>Overflowing a heap allocated buffer rather than a stack allocated buffer just results in heap corruption rather than stack corruption. At some point, you just have to make a call of how sloppy you think these libraries actually are, and if they're that bad you may need to e.g. isolate them to a separate process with limited permissions or something.</p>
</blockquote>
<p>Benjamin Lamowski implemented exactly this appraoch. (Paper: <a href="https://dl.acm.org/doi/10.1145/3144555.3144562">https://dl.acm.org/doi/10.1145/3144555.3144562</a>  Code: <a href="https://github.com/atopia/sandcrust">https://github.com/atopia/sandcrust</a>)</p>



<a name="226322616"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226322616" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tony Arcieri <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226322616">(Feb 14 2021 at 20:13)</a>:</h4>
<p>Speaking of stack overflow protection, I believe LLVM11 has portable stack probes, and I think that might've just gotten wired up (or at least an issue opened) in Rust recently</p>



<a name="226322676"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226322676" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tony Arcieri <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226322676">(Feb 14 2021 at 20:14)</a>:</h4>
<p>also there's <code>-Z sanitizer</code>: <a href="https://github.com/japaric/rust-san">https://github.com/japaric/rust-san</a></p>



<a name="226322703"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226322703" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tony Arcieri <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226322703">(Feb 14 2021 at 20:15)</a>:</h4>
<p>and this thread seems like the sort of thing that's up <span class="user-mention" data-user-id="130046">@Alex Gaynor</span>'s alley</p>



<a name="226322756"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226322756" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Alex Gaynor <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226322756">(Feb 14 2021 at 20:16)</a>:</h4>
<p>There's a recent patch (nightly, maybe beta) to take advantage of inline stack probes. Not sure if that's the same as portable ones though? (Makes it be an asm snippet instead of a call)</p>



<a name="226322760"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226322760" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tony Arcieri <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226322760">(Feb 14 2021 at 20:16)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/pull/77885">https://github.com/rust-lang/rust/pull/77885</a></p>



<a name="226322783"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226322783" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Alex Gaynor <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226322783">(Feb 14 2021 at 20:17)</a>:</h4>
<p>In terms of "does rust need <code>-fstack-protector</code>" it's not _just_ a question of whether Rust code uses this. If you have a stack array and then pass an address to a C function, you need the stack protection in the Rust function, not the C one.</p>



<a name="226322846"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226322846" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Alex Gaynor <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226322846">(Feb 14 2021 at 20:18)</a>:</h4>
<p>The ideal thing would be some sort of unsafe-aware stack-protector-strong, so only instrument functions that  both take the address of a stack array, and also do something unsafe with it.</p>



<a name="226322853"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226322853" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Alex Gaynor <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226322853">(Feb 14 2021 at 20:18)</a>:</h4>
<p>I do think it's an advantage to Rust that you don't need to instrument tons of functions for this, which has a perf cost.</p>



<a name="226323142"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226323142" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> tm <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226323142">(Feb 14 2021 at 20:26)</a>:</h4>
<p>More up to date documentation for <code>-Zsanitizer</code> is at <a href="https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/sanitizer.html">https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/sanitizer.html</a></p>



<a name="226629484"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226629484" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benjamin <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226629484">(Feb 17 2021 at 09:01)</a>:</h4>
<p>Thanks everyone for your input!</p>
<ul>
<li>Regarding heap allocation of data passed over FFI, I figured this might be safer because of the heap corruption protection mentioned in the exploit mitigation guide (<a href="https://doc.rust-lang.org/rustc/exploit-mitigations.html">https://doc.rust-lang.org/rustc/exploit-mitigations.html</a>). Also, maybe the chance is smaller of finding a function pointer in the vicinity, in contrast to stack overflow where there's a return address not far away. This would be a band-aid for the lack of stack-smashing protection at best though.</li>
<li>The stack probing mentioned is for stack <em>clash</em> mitigation, right?</li>
<li>The sanitizer flag sounds promising, though chiefly combined with the "safe-stack" sanitizer which fwict is intended for use in release builds. There's no support for this in rustc, even on nightly, correct?</li>
<li>Thinking more on the issue, I reached a conclusion similar to what <span class="user-mention" data-user-id="130046">@Alex Gaynor</span> points out: stack smash protection could benefit any function with a stack variable whose address is potentially passed to an unsafe block. The precise criterion should in practice be refined both to make analysis feasible and to strike a balance between security and performance (probably resulting in options similar to <code>-fstack-protector-{all,strong,}</code> as in gcc/clang, with the opportunity to make "strong" even stronger by excluding stack variables which are definitely only used by safe Rust). Notably though, this is not specific to C/C++ interop, since unsafe Rust code can be just as misbehaved? It's interesting to see that there have been few known vulnerabilities of this kind as <span class="user-mention" data-user-id="127617">@Shnatsel</span> mentions, but this may be an unsatisfactory assurance for the paranoid.</li>
</ul>
<p>I think my main concern is about marketing. The lack of hardening such as stack smash protection makes the choice between Rust and C/C++ by definition a trade-off security-wise, regardless of how uneven the trade might be: Rust code is less likely to contain vulnerabilities, but as it stands has fewer defences if shit hits the fan. Is this understanding correct?</p>
<p>I found an interesting if dated issue about adding a "stack smash protection" attribute to the generated LLVM functions (<a href="https://github.com/rust-lang/rust/issues/26612">https://github.com/rust-lang/rust/issues/26612</a>). Limited experimentation indicates that passing <code>-fstack-protector-{all,strong,}</code> to clang does more or less this: the output of <code>echo 'void f() { }' | clang++ -emit-llvm -x c++ - -S -o - -O2 &lt;ssp flag&gt;</code> delegates to LLVM by marking <code>f()</code> with a <code>sspreq</code>, <code>sspstrong</code>, or <code>ssp</code> attribute, respectively. Perhaps it's possible to build a rustc which adds these attributes without major compiler surgery?</p>



<a name="226656379"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226656379" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tony Arcieri <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226656379">(Feb 17 2021 at 13:38)</a>:</h4>
<blockquote>
<p>stack smash protection could benefit any function with a stack variable whose address is potentially passed to an unsafe block.</p>
</blockquote>
<p>I agree with this, and it came up a long time ago although I forget where the discussion went</p>



<a name="226656478"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226656478" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tony Arcieri <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226656478">(Feb 17 2021 at 13:39)</a>:</h4>
<p>here's an old issue about it, with someone asking at the end "is this tracked somewhere now?" <a href="https://github.com/rust-lang/rust/issues/15179">https://github.com/rust-lang/rust/issues/15179</a></p>



<a name="226656668"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226656668" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Alex Gaynor <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226656668">(Feb 17 2021 at 13:40)</a>:</h4>
<p>FWIW, it's not clear to me a precise analysis is possible (within the constraints of <code>rustc</code>) -- say you have <code>foo:f()</code> with a stack array. It calls <code>foo::g()</code> and passes a <code>&amp;[T]</code> to it, neither has an <code>unsafe</code> block. <code>foo::g()</code> then calls <code>bar::h()</code> (different module! different compilation unit!) <code>h()</code> does have an unsafe block.</p>
<p><code>f()</code> is where you need the canary, but the compiler has no way to know this.</p>



<a name="226712361"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226712361" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benjamin <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226712361">(Feb 17 2021 at 19:30)</a>:</h4>
<blockquote>
<blockquote>
<p>stack smash protection could benefit any function with a stack variable whose address is potentially passed to an unsafe block.</p>
</blockquote>
<p>I agree with this, and it came up a long time ago although I forget where the discussion went</p>
<p>here's an old issue about it, with someone asking at the end "is this tracked somewhere now?" <a href="https://github.com/rust-lang/rust/issues/15179">https://github.com/rust-lang/rust/issues/15179</a></p>
</blockquote>
<p>Thanks! The second-to-last post states that "we have some interest in a working group that would work on this stuff, and they'll track this in their own ways". Wouldn't that be this working group? ^_^;</p>
<blockquote>
<p>FWIW, it's not clear to me a precise analysis is possible (within the constraints of rustc) -- say you have foo:f() with a stack array. It calls foo::g() and passes a &amp;[T] to it, neither has an unsafe block. foo::g() then calls bar::h() (different module! different compilation unit!) h() does have an unsafe block.</p>
<p>f() is where you need the canary, but the compiler has no way to know this.</p>
</blockquote>
<p>Indeed, and starting out with heuristics similar to those offered by gcc/clang (none, some, strong, all) seems sensible to me, especially considering that they appear to be available out-of-the-box from LLVM and glibc. Safe Rust offers an opportunity for making <code>-fstack-protector-strong</code> more precise, but as you say it seems tough to answer the question "is this stack address definitely accessed by unsafe Rust". A better question is perhaps to ask "is this stack address definitely only accessed by safe Rust", and exempting stack frames from protection if the answer is "yes" for all stack variables whose address is taken. Perhaps there should be an extra option to decide if the standard library is trusted. </p>
<p>At any rate, I would consider having the choice of (none, some, strong, all) a major improvement over having no options at all, even if it turns out that strong ~= all for Rust code and requires Rust-specific adjustments to be meaningful.</p>



<a name="226714941"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226714941" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226714941">(Feb 17 2021 at 19:49)</a>:</h4>
<p>2¢: Don't trust the whole standard library.  Make something targeted and trust only those things.</p>
<p>(For example, maybe trust the small-size part of <code>swap_nonoverlapping_one</code>(<a href="https://github.com/rust-lang/rust/blob/5ef21063f0c0fd5b973bfa8cb88c0b70982da977/library/core/src/ptr/mod.rs#L451">https://github.com/rust-lang/rust/blob/5ef21063f0c0fd5b973bfa8cb88c0b70982da977/library/core/src/ptr/mod.rs#L451</a>) but not <code>swap_nonoverlapping_bytes</code> (until the latter gets a MIR proof or whatever.)</p>



<a name="226730398"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226730398" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tony Arcieri <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226730398">(Feb 17 2021 at 21:42)</a>:</h4>
<blockquote>
<p>2¢: Don't trust the whole standard library. Make something targeted and trust only those things.</p>
</blockquote>
<p>and this is why I write <code>no_std</code> applications <span aria-label="wink" class="emoji emoji-1f609" role="img" title="wink">:wink:</span></p>



<a name="226731060"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226731060" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226731060">(Feb 17 2021 at 21:48)</a>:</h4>
<p>Those methods are in core, so you're using them even in <code>no_std</code> <span aria-label="smiling imp" class="emoji emoji-1f608" role="img" title="smiling imp">:smiling_imp:</span> </p>
<p>(And as far as I know they're correct, and am not concerned about them in the slightest, but the bar "where to not do the just-in-case checks" should be seriously high.)</p>



<a name="226732295"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226732295" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226732295">(Feb 17 2021 at 21:57)</a>:</h4>
<p>I just discovered that <code>no_core</code> exists for the truly paranoid</p>



<a name="226732439"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226732439" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226732439">(Feb 17 2021 at 21:58)</a>:</h4>
<p>Apparently you have to fuss with lang items to actually do anything though. I would be curious to see what a minimal prelude library looks like that actually declares all lang iterms</p>



<a name="226732534"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226732534" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226732534">(Feb 17 2021 at 21:59)</a>:</h4>
<p>#![no_core] is perma-unstable though</p>



<a name="226734924"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226734924" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226734924">(Feb 17 2021 at 22:09)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/146229-wg-secure-code/topic/Stack.20smash.20protection/near/226732295">said</a>:</p>
<blockquote>
<p>I just discovered that <code>no_core</code> exists for the truly paranoid</p>
</blockquote>
<p>That's <em>irrationably</em> paranoid, though.  If you can't trust <code>core</code>, you <em>definitely</em> can't trust the compiler nor LLVM.</p>



<a name="226817046"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226817046" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226817046">(Feb 18 2021 at 14:26)</a>:</h4>
<p>Note that while not a <em>panacea</em>, there is always the possibility of using library-side canaries: <a href="https://play.rust-lang.org/?version=beta&amp;mode=release&amp;edition=2018&amp;gist=316165bb1feab341958656dd67f6acec">https://play.rust-lang.org/?version=beta&amp;mode=release&amp;edition=2018&amp;gist=316165bb1feab341958656dd67f6acec</a></p>



<a name="226981399"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146229-wg-secure-code/topic/Stack%20smash%20protection/near/226981399" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ammar Askar <a href="https://rust-lang.github.io/zulip_archive/stream/146229-wg-secure-code/topic/Stack.20smash.20protection.html#226981399">(Feb 19 2021 at 15:44)</a>:</h4>
<p><span class="user-mention silent" data-user-id="127617">Shnatsel</span> <a href="#narrow/stream/146229-wg-secure-code/topic/Stack.20smash.20protection/near/226310541">said</a>:</p>
<blockquote>
<p>FWIW, out of all the advisories in <a href="https://rustsec.org/">https://rustsec.org/</a> I've only seen one that would have been prevented by stack smashing protection. I could have missed something, but stack buffer overflow is not a common failure mode in Rust code.<br>
I'm not qualified to comment on the interaction with C code.</p>
</blockquote>
<p>Here's another example that came up recently: <a href="https://github.com/Alexhuszagh/rust-stackvector/issues/2">https://github.com/Alexhuszagh/rust-stackvector/issues/2</a></p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>